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DEVICE FOR TRANSFER OF MOBILE DATA AND CONTENT TO MOBILE HANDSETS 




METHOD AND DEVICE FOR USING DATA AND CONTENT IN MOBILE 

HANDSETS 

BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates 'generally to mobile data and content transfer 
methods and devices. More particularly the invention relates to a device useful in a 
variety of application, including - but not limited to - for example, devices for: (i) 
transferring data and content from an external device onto mobile handsets; (ii) activating 
server based mobile services, e.g., by sending a predetermined code or SMS message 
from an external device to a remote server; (iii) loading credits into prepaid accounts of 
customers as -payment for air time or as payment for any other mobile service or product, 
etc. 

Description of the Prior Art 

In the description to follow, the term "mobile handset" is used in its broadest 
sense, and should be interpreted to include all types of portable devices, cellular phones, 
handheld computers, PDAs, telephones, any wireless communication device, etc. 
Similarly, the term "external device", as will be apparent from the description to follow, 
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should be given its broadest interpretation and includes all kinds of devices that are 
capable of communicating in any way with a mobile handset, e.g., via IR or other optical 
link, ultrasound, RF or direct connection, and which contain data, or may receive data 
from an external source, which is transferable via said link to the mobile handset. Such 
external device may include, inter alia, smart cards, magnetic strips, memory cards, other 
mobile handsets, etc. 

Data transfer devices to mobile handsets are known in the art. Typically, data 
transfer devices to mobile handsets include the following technologies: 

1 . Smart card reader as accessory to mobile handsets - Mobile smart card readers exist as 
a part of the handset itself or part of its back cover or part of its battery or as a stand alone 
reader that is tailored to communicate with a limited number of handset models. Such 
mobile smart card readers are used for security, authentication, and electronic wallet 
applications in relation to financial and commerce applications, and in other mobile 
applications where the user has to be identified by a smart card in his/her possession. 

2. Smart cards exist in the market and usually contain memory means and a processor 
capable of performing cryptographic functions. Smart cards are developed as a secure 
solution for security, payment and other financial applications. 

3. Downloading and activating mobile services from the handset - Mobile handsets have 
the capability of receiving data services and content from servers over the air, via 
attachments to mobile messages (such as SMS or MMS), or part of internet 
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communication protocols such as WAP. In order to receive mobile data to the device the 
user activates the download process either from the device itself via messaging (by a 
SMS command for example) or by using mobile browsing technologies such as WAP, or 
by requesting the service from outside the mobile device, for example through a PC web 
site, or through an IVR system etc. In these manners a user can request a wide range of 
services such as picture downloads, ring tone downloads, live data services (such as 
weather updates), games and applications, and any other form of data and content that 
can reside on servers and be supported by mobile handsets. 

4. Transferring content into the handset from other devices (not as part of a cellular 
communication network) - Handsets support several ways of communicating with other 
local devices: 

4.1 through a physical plug that is usually connected to a PC or mobile accessory, 
such as a mobile camera. 

4.2 through an infrared port, that can communicate with other devices equipped 
with matching infrared ports. 

4.3 through a Bluetooth port, that can communicate with other devices equipped 
with matching Bluetooth ports. 

5. The sale of air time or other credit (such as credit to purchase content) for prepaid 
accounts via scratch cards - The sale of air time or other credit for prepaid accounts is 
done in two major ways: 
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5.1 PIN (personal identification number) based solutions - A PIN number 
(sometimes called a Hidden Reload Number) is used to create credit or credit accounts, 
and is hidden by scratchable material on cards, these cards are then sold. To credit or 
charge (top-up) the account the user has to do the following: buy the card, reveal the PIN 
code number, contact the prepaid account manager (via IVR for example) transfer the 
PIN code number - and in return be credited with the same amount as he paid for the card 
containing the PIN number. 

5.2 PINless solutions - the user pays for the credit at a point of sale that is 
connected to the credit management system, and the credit is updated on line at the time 
of purchase. 

6. Paper cards with buttons - The technology needed to provide buttons on thin cards 
exists and is being used mainly in the greeting card and low-cost promotional items 
industry, to provide user interface for items such as thin calculators, and playing musical 
tunes on greeting cards. Common button methods are pressure buttons, in which a small 
metal spring has to be pressed to close a circuit, and conductive buttons, in which the 
button is printed on the card as a broken electricity line, and the human finger closes the 
circuit when the key is pressed. Buttons have also been provided on smart cards. 

The main problem with conventional data transfer devices to mobile handsets is that 
smart card readers are not used in content application due to their high cost and the cost 
of smart cards, thus preventing the use of this technology for mass-market content 
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applications, where the distribution of large number of cards per user is the goal, and 
therefore a low manufacturing cost is a must. 

Another problem with existing products is that no universal data transfer system into at 
least the most common mobile handsets exists, to cope with the diversity of mobile 
handsets: 

- Different physical plugs. 

- Different wireless connection methods. 

- Different communication protocols. * 

- Different displays: size, resolution, colors etc. 

- Different support for multimedia content. 

- Different menu path (for macros). 

- Different operating systems, and application platforms. 

Therefore existing solutions are limited in terms of cost, inventory management, and the 
ability to have full coverage of the handsets in the market in order to allow mass 
deployment of any application that targets mass audiences. 

Another problem with existing products is that existing smart card readers do not have a 
"field upgradable" capability, and therefore cannot adapt to new models and new 
requirements of handsets as they reach the market. 

< 
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A further problem with existing products is that smart cards do not have a developed user 
interface, such as buttons on them which have a functional use, therefore they do not 
provide control by the user of the applications for which they are used. 

Still another problem with conventional mobile data transfer device is that when users are 
trying to download mobile content over the air they face two major limitations: 

1. Usability - the user interface involved in downloading content is not direct and 
not simple, it involves several stages such as compiling a coded message and sending it to 
a predefined number. 

2. Visibility: A wide range of content exists somewhere in the "cloud" of 
cyberspace, but the user has no way of knowing what all the options are, and the content 
providers have very few ways of letting the user know that content is available - in effect 
most of the mobile content is "hidden" from the user because it is not clearly visible to 
him. 

Usability and Visibility as described above are the two main problems limiting the usage 
of mobile data, mobile downloads, the usage of content as an attachment in messages 
(i.e., SMS, MMS), and all other mobile services that providers want to sell or distribute 
to users. 

Another problem with existing products is that there is no way of selling or distributing 
mobile content at a low cost in a physical manner for example in retail points of sale. 
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Another problem with existing products is that there is no way of selling or distributing 
mobile games and applications at a low cost in a physical manner in a way that protects 
the game or application from being pirated. 

Another problem with existing products is that the sale of prepaid credit through scratch 
cards is limited in terms of marketing power and security; the main reason for this is that 
scratch cards are valuable because they contain a "live" PIN number which is equivalent 
to money, therefore they can not be prominently displayed at points of sale for fear of 
theft, and therefore can not be used "as a marketing platform, and can not give the 
provider of the cards all of the advantages of displaying attractive cards in good locations 
at points of sale. 

While existing devices may be suitable for the particular purpose which they address, 
they are not as suitable for transferring data and content from a low cost device onto 
mobile handsets by way of uploading the data and the content from the device onto the 
mobile handset; and not as suitable for activating server based mobile services by way of 
sending a predetermined code or SMS message from the device to a remote server; and 
not as suitable for loading credits into prepaid accounts of customers as payment for air 
time or for any other mobile service. 

In these respects, the universal device for transfer of mobile data and content to handsets 
according to the present invention substantially departs from the conventional concepts 
and designs of the prior art, and in so doing provides an apparatus primarily developed 
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for the purpose of transferring data and content from the device of the invention onto 
mobile handsets, by way of uploading the data and the content from the device onto the 
mobile handset; activating server-based mobile services by way of sending a 
predetermined code or SMS message from the device to a remote server, loading credits 
into prepaid accounts of customers as payment for air time or for any other mobile 
service, etc. 

SUMMARY OF THE INVENTION 

In one aspect, the present invention provides a new universal device for transfer 
of mobile data and content to handset construction wherein the same can be utilized for 
transferring data and content from said device onto mobile handsets, by way of uploading 
the data and the content from said device onto^the mobile handset; activating server based 
mobile services by way of sending a predetermined code or SMS message from our 
device to a remote server; loading credits into prepaid accounts of customers as payment 
for air time or for any other mobile service. 

As will be apparent to the skilled person, the device of the invention, which will 
be described hereinafter in greater detail, provides a new universal means for the transfer 
of mobile data and content to handsets, which has many of the advantages of the mobile 
data transfer device mentioned heretofore and many novel and important features. 
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Brief Description of the Drawings 

Fig. 1 schematically shows an external device, including reading, transmitting and 
memory elements, according to one preferred embodiment of the invention; 

Fig. 2 schematically shows the reading element of the external device of Fig. 1; 

Fig. 3 schematically shows the memory element of the device of Fig. 1; and 

Fig. 4 schematically shows transmitting elements of the device of Fig. 1, 
according to three different preferred embodiments of the invention. 

Detailed Description of Preferred Embodiments 

Referring to the drawings, an external device according to one specific preferred 
embodiment of the invention comprises: 

1. A phone bridge (transmitting element) [80], having connectors at either end, which 
functions as a bridge for the transfer of data and content between the mobile handset and 
the reader [10] by virtue of a connection to the handset such as a physical connection, i.e., 
a clip or connector, or such as an IR connection (a method of transferring content and 
data to the mobile handset in lieu of a physical connection), or such as a Blue Tooth 
connection (a method of transferring content and data to the mobile handset in lieu of a 
physical connection) on the one side, and by virtue of a physical connector which 
attaches the phone bridge to the reader on the other side; 

2. A reader (reading element) [10] which is attached to the phone bridge [80] on the one 
side by virtue of a physical connector [14] (as described above) and which is connected 
to the card [50] on the other side by means such as a slot [12] into which the card is 
inserted, or a docking station; 
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3. The software which is located in the reader, and 
is described in detail below. 

4. The card (memory element) [50] is a flat element, which can be made of materials such 
as plastic or paper and is provided with buttons [56], as well as with non- volatile memory 
[60], and is connected to the reader [10] by means such as a slot [12] into which the card 
is inserted, or a docking station or the like; 

The data structure which is created by connecting the mobile handset to the phone bridge 
(as described above) and by connecting the phone bridge to the reader (as described 
above) and by connecting the reader (which contains the software) to the card (as 
described above) cooperates to carry out the invention. 

The phone bridge [80] is an elongated component with two ends. On the one end there is 
connector [82] which creates a path for the transfer of data to the mobile handset. The 
form of the connector to the mobile handset depends on the characteristics of the mobile 
handset to which it is connected, and" such connector may be (but is not limited to) a 
physical connector [90] which is inserted into the data connector slot on the mobile 
handset, or it may be a IR connector [86] which is capable of transferring data by infra- 
red beaming, or it may be a Blue Tooth connector [88] which is capable of transferring 
data by means of wireless protocol. The other end of the phone bridge [84] connects to 
the reader and it can clip or snap on to the reader by any variety of spring attachments or 
similar means. 
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The reader [10] comes in the form of a rectangle but other shapes are also applicable. 
Two of the readers' sides are longer than the other two sides (the "length sides"). One of 
the length sides has a connector [14] to the phone bridge on it. The other length side has a 
slot [12] into which the card can be inserted. The card [50] is locked into the reader 
firmly after insertion by a docking system [12] such as a spring attachment or similar 
means. 

The software is stored and is run, in this particular embodiment of the invention, on 
subcomponents of the reader (the processor unit [24]), the software's main purposes are 
to interact with the card [50], reading and writing data and processing commands from 
and to the card; to manipulate the data so that it is suitable to be received by the handset 
to which it is being connected; and to transfer the data and commands into the mobile 
handset through the bridge, by running communication protocols and supporting mobile 
handset protocols as required by every handset supported. 

The card [50], according to this particular preferred embodiment of the invention, is a 
flat, credit card like object which can come in various sizes and shapes. It can be made of 
different materials, including paper and plastic. Embedded in the card are buttons [56], 
and a memory chip [60] which is located on the card and contains data and commands. 
On the same side as the buttons is a connector [52] mechanically and electronically built 
to fit into the card docking area in the reader [12], and when inserted into the reader, the 
card plus the reader plus the bridge plus the handset function together as a unit, 
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transferring data and commands from the card to the handset and the other way around 
through the reader and the bridge. 

The data structure can best be described as following: The memory [60] in each card will 
contain one or more items. Each item will be logically "packaged" and internally 
arranged in one of a set of predefined sub-structures. Each data sub-structure will 
describe one group of items supported by the system such as "text content sub-structure" 
or "picture file substructure". Each sub-structure is a defined and documented description 
of the content of the data item, its elements and the parameters of each element. All the 
items in the cards will be stored according to sub-structures, and the software in the 
reader will be programmed to read and write such sub-structures from and to the card. 
The collective of all the sub-structures is defined as the "data structure". 

The invention will no be described in greater detail. However, it should be understood 
that the invention is not limited in its application to the details of construction and to the 
arrangements of the components set forth in the following description or illustrated in the 
drawings. The invention is capable of other embodiments and of being practiced and 
carried out in various ways. Also, it is to be understood that the phraseology and 
terminology employed herein are for the purpose of the description and should not be 
regarded as limiting. 
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The purpose of the phone bridge is to enable the transfer of data between the reader and 
as many phone models as possible, therefore, by design, there will be provided multiple 
types of phone bridges, to support many models of phones supported by the universal 
reader. 

The subcomponents within the bridge are: 

1. The connector to the reader [84]: A corresponding connector to the connector found on 
the reader [14]. 

2. Plastic casing [82]. 

3. Connector to the mobile phone: As will be apparent to the skilled person, the connector 
chosen will be suitable to meet whatever capabilities and protocols the corresponding 
phone models supports. The skilled person will know without the need for undue 
experimentation, based on the characteristics of the mobile handset (e,g., cellular phone), 
how to provide suitable phone bridges to meet the standard connection offered by 
manufacturers today and in the future. Several examples are: 

3.1. Infra Red phone bridges [86]: designed to work with phones containing an 
Infra Red communication device. This bridge family will include a standard Infra Red 
communication unit. This family may include different models that will have different 
Infra Red communication units to meet different Infra Red standards, such as IRDA. 

3.2. Bluetooth bridges [82]: designed to work with phones containing a Bluetooth 
communication device. This connector family will include a standard Bluetooth 
communication unit. This family may include different models that will have different 
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Bluetooth communication units to meet different Bluetooth standards, such as Bluetooth 
1.0. 

3.3. Plug Bridges [90]: many phones come with slots for data connectors, which 
were designed to interface a plug connected to a PC or a phone accessory. Plug bridges 
are interfaces to such slots built to the standard set by the corresponding phone 
manufacturer. 

3.4. Back cover bridges: In some phones, the back cover is a separate component; and its 
manufacturers are placing some electric connectors exposed, so that back covers can 
interface with the phone, in such models, the back cover itself will include both the body 
of the reader, and the bridge, as originally designed by the phone manufacturers. 
Alternatively, the bridge can interface the phone using a technology called "dual SUM 
slots", which is available for many phone models. 

3.5. Phone battery bridges: In some phones, the battery is a separate component; 
and its manufacturers are placing some electric connectors exposed, so that phone 
batteries can interface with the phone, in such models, the battery itself will include both 
the body of the reader, and the bridge, as originally designed by the phone manufacturers. 
Alternatively, the bridge can interface the phone using a technology called "dual SIM 
slots", which is available for many phone models. 

In some models, the reader and the bridge will be permanently connected, and therefore 
will be a single subcomponent without the connectors on both sides. 
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The universal reader is shown at numeral [10] in the form of a rectangle, but other shapes 
are also applicable. Two of the reader's sides are longer than the other two sides (the 
"length sides"). One of the length sides has a connector [14] to the phone bridge on it. 
The other length side has a slot [12] into which the card can be inserted. The card [50] is 
locked into the reader firmly after insertion by a docking system [12] such as a spring 
attachment or similar means. 

The universal reader is a mobile device that transfers data between, on the one hand, the 
cards (as described below as the cards subcomponent), and on the other hand, multiple 
types of mobile handsets and PDAs and other mobile communication devices, while 
overcoming the diversity of mobile handset communication capabilities, connector 
differences (i.e., IR, Bluetooth, physical clips), protocols supported, media handling 
capabilities, and more as described below. The reader comprises the following sub 
components: 

1 . The casing, made of a low cost material such as plastic, and composed of a back side 
[16], and a front side [14]; 

2. The docking station (card interface) [12]: a card holder such as a slot, into which the 
cards or accessories can be attached, with at least six electrical connectors [11] 
corresponding to the electrical connectors on the cards, and with a mechanical device that 
"locks" the card into place employing any suitable locking mechanism, so that it may be 
comfortably removed by a user but will not fall out when not pulled by a user. 
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3. The power unit [22]: a portable power source such as a battery replaceable or 
permanent or a rechargeable battery, or a converter that would take its power from the 
phone (through the connector), and turn it to the power parameters required by the reader. 

4. The processor circuit [24]: a unit consisting of one or more electronic chips, that will 
be responsible for storing the reader's software and executing the software as described 
with reference to the "Software" subcomponent 

5. The board [26]: an electric board connecting the various elements of the reader 
together. 

6. The reader's connection to the phone bridge [14]: The reader will be connected to the 
bridge described below, via a mechanical connector, which will insure that the body and 
the phone bridge are secured, and will allow the user to separate them. The phone bridge 
and the reader will be connected electronically through at least six connectors, as shown 
in Fig. 2 In some models, the reader and the bridge will be permanently connected. 

The following are additional sub-components that may be added to the reader in some 
versions: 

1. The buttons: the reader may or may not include buttons, such as control buttons, 
depending on future customer requirements for the tailoring of the device to different 
applications. 

2. Display: the reader may or may not include a display, depending on future customer 
requirements for the tailoring of the device to different applications; such display might 
be used for showing the user what is available on the card, so that the user can browse the 
content of a card without a mobile handset present. 

— * 
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3. Light indicator [20]: the reader may or may not include light indicators, such as red or 
green LEDs, depending on future customer requirements for the tailoring of the device to 
different applications; such light indicators might be used for signaling the status of the 
device to the user. 

4. Sound indicator [28]: the reader may or may not include sound indicators, such as a 
beeping speaker, depending on future customer requirements for the tailoring of the 
device to different applications, such sound indicators might be used for signaling the 
status of the device to the user. 

5. A button device driver: A button device driver responsible for managing multiple 
buttons on a card and communicating to the processor which button was pressed - in the 
basic design such driver is located on the card, but in other version such device driver can 
reside on the reader and can also be programmed into the software running on the reader's 
processor. 

The readers' software: the software running on the reader's processor is designed to 
support all the operation and usage-scenario modes described below. The software 
running on the reader's processor can generally be described as having three layers. 

Layer 1: Card communication: This layer reads and, if desired, writes data sub- 
structures (explained in the "data structure" component below) to and from the card - for 
example when reading a picture. This layer also receives and sends commands from and 
to the card - for example, when receiving a message that a button was pressed by the 
user. 
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Layer 2: Central management and control of the reader deciding what to do at 
each point in time, packaging the data to meet the specifications required by the phone 
(using the functions described below), and managing layers 1 and 3 in synchronization, 
and monitoring operation and status. 

Layer 3: Phone communication: communicating with the phone, using the 
protocol appropriate for the "phone bridge" used, and the phones capabilities and 
supported protocols, to send and receive data structures defined by the phone 
manufacturer. 

Additional main software functions may include: 

Function 1 : data packaging for the phone: each phone model has different data structures 
in which it packages the data it sends and/or receives via its communication ports. This 
function is phone-model specific, and knows how to match and convert between, on the 
one hand, the data sub-structures of the invention (described below) and on the other 
hand, the data structures appropriate for the phone. 

Function 2: Phone model adjustments: this function is responsible for delivery from layer 
1 to layer 3 of the "most suitable" content that the specific phone model can support. For 
example the card may contain both a black & white picture and a color picture for the 
same button, and this function, will know it has to match a B&W picture to B&W phone 
models and a color picture to color phone models. Another example is adjusting the 
resolution of a picture stored in the card to match the resolution of the phone's display. 
Function 3: Decryption - a function to decrypt an encrypted code. 
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"Field upgradable" functionality: The software will support the "live update" of software 
elements in the reader's memory, meaning that there are sub-structures defining 
"software updates", and the software will be capable of reading such "software update 
sub-structures" from cards, and of adding them into the software itself while it is running. 

In the cases where the reader is incorporated into the phone, the software may be stored 
and run on the storage and processors of the handset itself - thus making the handset itself 
"the reader". In such cases the layer dealing with the communication to the handset (layer 
3 above) will be in charge of reading and writing directly into the handset data storage 
areas, and communicating with the user interface devices of the handset such as keys and 
display. | 

Cards [50] are components that fit into the reader's docking station as described above in 
the reader section, and can communicate with the reader, using the data structures 
described below. The card consists of the following subcomponents: 

1. The cards 1 body [54]: it can come in any shape or size for example a card the size of a 
credit card. It can be made of many materials such as but not limited to PVC or paper. 
Different graphic designs can be printed on the cards to meet customers' specifications. 

2. The cards memory unit [60]: ROM, RAM, Rash, EEprom, Eprom or other forms of 
memory. 
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3. The cards connectors [52]: a set of at least six connectors corresponding to the 
connectors inside the readers docking station. 

4. The cards buttons [56]: the card will have buttons on it. There are several types of 
possible buttons as described above, such conductive buttons that close a circuit when a 
finger presses them, pressure buttons or other types of buttons. 

5. A button device driver 62]: A button device driver responsible for managing multiple 
buttons on a card and communicating to the reader which button was pressed. 

6. An electric circuit [58]: which connects the different card elements such as the 
memory and the buttons device driver to the connectors, connects the buttons to the 
buttons device driver, etc. 

Possible additional versions of the card include: 

1. The card may have no buttons on it, for example a card that is designed to upload its 
content immediately upon insertion to the reader, or a card designed to work with a 
reader version that has operating buttons on the reader. 

2. The card may not include a button device driver, in the case that the buttons are linked 
directly to the reader, and the reader will include button device driver functionality, in 
case the buttons are on the reader, and the card has no buttons on it. 

3. The card may include a standard magnetic strip, for the storage of small amount of 
data, and to allow the card to be swiped in retail outlets that are equipped to swipe 
magnetic stripes such as the one found on the back of credit cards. 
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4. The card may include printed information hidden behind a stripe of scratch-able 
material, or behind a (sticker), similar to scratch cards mentioned above. 

5. The cards connectors may be hidden or rendered inoperable by a conductive (sticker) 
or (opaque cover or coating) - so that the content of the card can not be read until this 
(sticker) or (opaque or coating) is removed from the card. This method works in two 
ways: firstly, because of the sticker or the opaque coating the card cannot mechanically 
be inserted into the reader until such cover is removed; secondly, even if a hacker tries to 
hack into the card by trying to touch the connectors directly the hacker will be blocked by 
the fact that the cover is conductive arid therefore all of the connectors are connected to 
each other until the cover is removed. 

6. Light indicator: the card may include one or more light indicator such as LED, for 
example to signal to the user the occurrence of actions or events on the card. 

7. The card may have a camera or video camera connected to it. 

8. The card may have a mobile GPS device. 

9. The card may have a mobile electronic pen or other pointing device or sketching 
device. 

10. The card may have a qwerty keyboard or other keyboard on it. 

11. The card may have any other different mobile accessory that otherwise is connected 
to phones using non-universal connections. 

The memory in each card will contain one or more items. Each item will be logically 
"packaged 11 and internally arranged in one of a set of predefined sub-structures. Each data 
sub-structure will describe one group of items supported by the system such as "text 
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content sub-structure" or "picture file substructure". Each sub-structure is a defined and 
documented description of the content of the data item, its elements and the parameters of 
each element. All the items in the cards will be stored according to sub-structures, and the 
software in the reader will be programmed to read and write such sub-structures from and 
to the card. The data structure is the logical way of making sure that all the cards speak 
the same "language" with all the reader, so that the cards can be sold independently of the 
types of handsets out in the market. Some illustrative and non-limitative examples of data 
sub-structures are: 

1. A content data sub-structure, such as the following examples: 

l.a. Text 

l.b. A picture, (multiple formats such as JPG, GIF) 

I.e. An animation (multiple formats such as GIF) 

l.d. Audio or music file (multiple formats such as AVI, MP3) 

I.e. Ring tone file (multiple formats) 

l.f. Video (multiple formats such as MPEG4) 

l.g. A karaoke file, containing a melody, and a text corresponding to each 
element of the melody. 

l.h. A theme file (also known as an album) - a collection of several other file 
formats bundled into a single entity. 

2. A macro command - a predefined set of keystrokes to be executed one after the other 
on the phone. 
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3. A preset mobile message - a full or partial mobile message to be sent through the 
phone (multiple formats such as SMS, EMS, MMS, e-mail), such preset message will 
include the content of the message, the attachments, the address of the recipient such as a 
phone number, and any other information required by the messaging protocol used. 

4. A code - a set of characters, usually different code is assigned to each individual card. 

5. An encrypted piece of information. 

6. A software application or game, written in mobile phone software systems such as 
JAVA or BREW. 

7. General data elements: such data will be transferred to the phone as is, with the 
assumption that the phone knows what to do with it. (One example is input data for a 
software application or game), the header of this data sub-structure will define it as a 
"general data element" and it will be passed on to the phone as is. 

8. A software element for the reader - such data sub-structure is used in "Maintenance 
cards" to upgrade or fix the software of the reader. The data in this type of item is not 
transferred to the phone, but instead is used to replace portions of the reader's software as 
needed. 

9. A combination data sub-structure: a "super sub-structure" which houses two or more 
data sub-structures to be implemented one after the other, for example, a SMS message 
plus a macro command in a single data sub-structure. A data sub-structure may support 
several alternative files for the same item, for example for a picture item, the data sub- 
structure will support the storage of both a black and white, and a color picture - in the 
same data sub-structure element. Some illustrative used (also called hereinafter 
"scenarios") of the device of the invention will now be described. 
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Typically, the reader and the bridge will be sold connected, or will in most cases be 
connected immediately after purchase and will remain connected and carried as a single 
unit. Therefore the term "the reader", as used herein, includes the reader either alone or 
when connected to the bridge. 

As a rule, when the reader communicates with the handset, it uses communication 
protocols and capabilities defined by the handset manufacturer. Therefore, any 
applicability of each scenario described herein to a specific phone model depends on the 
support of that handset model for such function. For example a scenario describing the 
upload of a color picture to a handset depends on the capability of that model to store and 
present color pictures. 

In addition the programming of the software to perform the actions described herein will 
be according to handset manufacturer's instructions, and in some cases, even using code 
supplied by the handset manufacturer. All the scenarios described herein are applicable to 
handsets that are available on the market. 

All operation scenarios relate to the use of 3 hardware elements together, which will be 
termed the "system". The "system" includes: 1. a Mobile handset (usually a phone or 
PDA); 2. A Reader (as mentioned above, with the bridge already connected to it); and 3. 
A Card. 
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Most operation scenarios include the basic function termed as: "press a button" this basic 
function is described as follows: 

1. The user inserts a card into the reader, 

2. The user makes sure the reader is "connected to the phone" 
This depends on the bridge type used, for example: 

- In a "physical plug bridge", the user snaps the plug into the phone. 

- In an "Infra-Red bridge" the user turns the "receive via infrared" in the phone to "On", 
and point the reader to the JR port of the phone". 

- In a Bluetooth bridge, the user turns the "receive via Bluetooth" in the phone to "On" (in 
some handset models it is on as default) , and holds the reader close enough (10 meter). 

- In a back cover or battery reader, the reader is mounted on the handset therefore no 
additional action is needed. 

3. The user activates a system action - usually by pressing a button on the card. But in 
other system versions it can be done by pressing a button on the reader (if the reader has 
buttons on it) or on the handset (in some models where the reader is part of the back- 
cover). 

Actions 1-3 above will be termed "press a button". 

The following is a list of the scenarios using this "press a button" action: 

Scenario 1: Mobile content upload: 
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Description of the card used in this scenario: 

A card with buttons that corresponds to content items that reside on the card's memory. 
Description of the scenario: 

User "presses a button" and the content is |ploaded through the reader and into the 
appropriate storage area in the handset. 

Examples: 

l.a The upload of a text sentence from the card into the list of template SMS messages on 
the handset. 

l.a The upload of a picture file from the card into the list of picture files on the handset. 
1 .c The upload of a ring tone from the card into the list of ring tones on the handset, 
l.d The upload of a animation from the card into the list of animations on the handset. 

This scenario is applicable to all other content types described in the "data structure" 
components, such as multimedia files, software file, and any other type of content 
supported by handset models. 

Scenario 1.1 : content upload as part of sending a mobile message. 
Description of card used in this scenario: 

A card with a button that corresponds to a content file that resides on the card's memory. 
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Description of the scenario: 

User "presses a button" and the content is uploaded into this content type storage area in 
the phone, and displayed on the phone for viewing (by the handset). The user 
immediately uses the phone's own menu to send this picture via a mobile messaging 
technology such as SMS, EMS, MMS, picture-messaging or mobile email to someone 
else. 

Remark: 

This scenario is applicable to all content types described above, with the necessary 
adjustment, (for example an audio file is played and then sent by the user). 

Scenario 2: Activation of "macro commands" from the card. 
Description of card used in this scenario: 

A card with a button that corresponds to a "macro command" file (as defined in the data 
structure component section above) that resides on the cards' memory. 

Description of the scenario: 
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User "presses a button" and the command is re-played on the phone, keystroke by 
keystroke, for example, a "Macro command" that mimics the "Clear 11 keystroke, followed 
by a set of digit keystrokes, followed by a "Yes" keystroke, will, when executed by the 
"press a button" action - cause the phone to call the number that the digits in the macro 
represent. 

Remark: 

Can be used to activate existing menus on the phone. Can be used to change set-up of the 
phone, start applications (like calculator etc.) 

Scenario 3: sending preset messages from the card through the phone. 
Description of card used in this scenario: 

A card with a button that corresponds to a "preset message" file (as defined in the data 
structure component section above) that resides on the card's memory. 

Description of the scenario: 

User "presses a button" and the reader takes the preset message from the card and sends it 
to its preset destination through the handset. In this case the handset is just used as a 
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communication device to send the message through, using protocols defined by the 
handset manufacturer. 

Remark: 

Can be used to send all types of mobile messages as supported by the phone. 

Scenario 3.1: sending preset messages with attachments from the card through the phone. 

Description of card used in this scenario: 

A card with a button that corresponds to a "preset message" file (as defined in the data 
structure component section above) that includes an attachment such as a multimedia file, 
which resides on the cards' memory. 

Description of the scenario: 

User "presses a button" and the reader takes the preset message with the attachment from 
the card and send it to its preset destination through the handset, in this case the handset 
is just used as a communication device to send the message through, using protocols 
defined by the handset manufacturer. 

Remark: 

Can be used to send all types of mobile messages as supported by the phone. 
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In some models the attachment can be of a type that is not supported by the phone for 
display - only supported for sending, for example, an EMS message which can include an 
icon picture, can be sent in this way through a phone that does not support the display of 
EMS message and icons, but since EMS is just a concatenation of several SMS messages 
together - this scenario allows the sending of EMS messages including icons from phones 
that support only SMS and not EMS. 

Scenario 4: sending preset messages from the card through the phone - in order to begin a 
remote service such as a content download. 
Description of card used in this scenario: 

A card with a button that corresponds to a "preset message" file (as defined in the data 
structure component section above) that resides on the card's memory. 
Description of the scenario: 

User "presses a button" and the reader takes the preset message from the card and sends it 
to its preset destination through the handset. The remote server receives the preset 
message which is actually and command and responds accordingly by activating the 
requested service. 

Scenario 5: sending preset messages from the card through the phone - in order to deliver 
a code to a destination, such as activation codes for pre-paid mobile airtime accounts. 
Description of card used in this scenario: 
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A card with a button that corresponds to a "preset message" file (as defined in the data 
structure component section above) that resides on the card's memory. 
Description of the scenario: 

User "presses a button" and the reader takes the preset message from the card and sends it 
to its preset destination through the handset. Once the message is received the user's 
account is credited accordingly. 

Scenario 6: uploading a software application (Java, BERW) to the phone. 
Description of card used in this scenario: 

A card with a button that corresponds to a content file that resides on the card's memory. 
Description of the scenario: 

User "presses a button" and the software application is uploaded into this aplication type 
storage area in the phone, and displayed on the phone for viewing and use (by the 
handset). The user immediately uses the phone's own menu to activate and use the 
application. 

Scenario 7: Communicating with a software application (Java, BERW) in the phone. 

Scenario 7.1: putting some of the functions of a game onto a card according to the 
invention, 
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Scenario 8: top-up card - sending preset messages from the card through the phone - in 
order to deliver a code to a destination, such as activation codes for pre-paid mobile 
airtime accounts. 

Scenario 9: Top-up card - using any suitable covering technique. 

Scenario 10: Top-up card - using any suitable covering technique with the same (or 
other) code also printed on the card and covered, for example with a "scratch" material. 

Scenario 11: Top-up card, with the code encrypted, using a decrypting reader on the Point 
of Sale, prior to the sale. 

Scenario 11: Top-up card, with the code added to it at the Point of Sale, prior to the sale. 

Scenario 12: Multi-use Top-up card, that carries the details of the phone number and 
mobile-operator on the memory of the card, and works with a corresponding reader at the 
point of sale. 

Scenario 13: Multi-use Top-up card, that carries the details of the phone number and 
mobile-operator on the memory of the card, and works with any reader that was 
authorized to top-up that specific phone (such as a child's parents). 
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Scenario 14: Multi-use Top-up card, that carries the details of the phone number and 
mobile-operator on the card on a magnetic strip, and works with a corresponding reader 
at the point of sale. 

Scenario 15: Multi-use Top-up card, that carries the details of the phone number and 
mobile-operator on the card on a magnetic strip, and works with a corresponding reader 
at the point of sale. 

As to a further discussion of the manner of usage and operation of the present 
invention, the same should be apparent from the above description. Accordingly, no 
further discussion relating to the manner of usage and operation will be provided. 

With respect to the above description then, it is to be realized that the optimum 
dimensional relationships for the parts of the invention, to include variations in size, 
materials, shape, form, function and manner of operation, assembly and use, are deemed 
readily apparent and obvious to one skilled in the art, and all equivalent relationships to 
those illustrated in the drawings and described in the specification are intended to be 
encompassed by the present invention. 

Therefore, the foregoing is considered as illustrative only of the principles of the 
invention. Further, since numerous modifications and changes will readily occur to those 
skilled in the art, it is not desired to limit the invention to the exact construction and 
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operation shown and described, and accordingly, all suitable modifications and 
equivalents may be resorted to, falling within the scope of the invention. 
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CLAIMS: 

L A device for sharing data from an external data source with a mobile handset, 
comprising: 

- reader means, suitable to read data from a detachable data source; 

- transmission means, suitable to transmit data read by said reader means to said 
mobile handset; and 

software means to covert the data read by said reader into data transferable by 
said transmission means. 

2. A device according to claim 1, wherein the reader means comprise contact reading 
means. 

3. A device according to claim 1, wherein the reader means comprise contactless reading 
means. 

4. A device according to claim 1, wherein the transmission means comprise optical or 
radio transmitting means. 

5. A device according to claim 4, wherein the optical transmitting means comprise an IR 
port. 

6. A device according to claim 4, wherein the radio transmitting means are selected from 
RF and Bluetooth transmitters. 
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7. A device according to claim 1, wherein the transmission means comprise direct contact 
connecting means. 

8. A data set comprising in combination: 

a) A device for sharing data from an external data source with a mobile handset, 
comprising: 

- reader means, suitable to read data from a detachable data source; 

- transmission means, suitable to transmit data read by said reader means to said 
mobile handset; and 

software means to convert the data read by said reader into data transferable by 
said transmission means; 
and 

b) Memory means containing data. 
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